What the bug is

Before this PR, examples/client-quickstart/tsconfig.json and examples/server-quickstart/tsconfig.json were standalone configs that matched the tsconfig.json blocks in their respective quickstart docs field-for-field on target/lib (client: ES2023/[ES2023]; server: ES2022/no lib). After this PR, both example tsconfigs were rewritten to "extends": "@modelcontextprotocol/tsconfig" and dropped their own target/lib entries. The shared base at common/tsconfig/tsconfig.json:3-4 sets "target": "esnext" and "lib": ["esnext"], and the example overrides only touch outDir, rootDir, declaration, declarationMap, types, and paths — not target/lib. So both examples now compile with an effective target of esnext, while the docs still tell users to use ES2023 / ES2022.

The specific code path

• docs/client-quickstart.md:91-92 → "target": "ES2023", "lib": ["ES2023"]
• examples/client-quickstart/tsconfig.json → extends @modelcontextprotocol/tsconfig, no target/lib override → effective esnext/[esnext]
• docs/server-quickstart.md:106 → "target": "ES2022", no lib
• examples/server-quickstart/tsconfig.json → extends @modelcontextprotocol/tsconfig, no target/lib override → effective esnext/[esnext]

This is a new drift introduced by the PR. The PR already fixed the module/moduleResolution drift in the same doc blocks (raised in an earlier review comment), but the consolidation onto the shared base introduced fresh drift on target/lib that wasn't propagated.

Why existing checks don't catch it

The tsconfig.json blocks in both docs are plain ```json fences with no source= attribute, so `pnpm sync:snippets --check` does not compare them against the example files. The `.ts` code snippets in the docs are `source=`-tagged and synced from the example sources — which means CI typechecks those snippets under the example's effective `target: esnext`, while the doc tells the user to compile with `ES2023`/`ES2022`.

Step-by-step proof

1. Open common/tsconfig/tsconfig.json — lines 3-4 set "target": "esnext", "lib": ["esnext"].
2. Open examples/client-quickstart/tsconfig.json after this PR — it has "extends": "@modelcontextprotocol/tsconfig" and its compilerOptions override sets outDir, rootDir, declaration, declarationMap, types, paths but not target or lib. Effective target is therefore esnext.
3. Open docs/client-quickstart.md:91-92 — it still shows "target": "ES2023", "lib": ["ES2023"].
4. Same chain for the server quickstart: examples/server-quickstart/tsconfig.json inherits esnext, but docs/server-quickstart.md:106 shows "target": "ES2022" with no lib.
5. Before the PR (git show HEAD~3:examples/client-quickstart/tsconfig.json), the example was standalone with "target": "ES2023", "lib": ["ES2023"] — identical to the doc block. The drift is introduced here.

Impact

No runtime breakage today — the quickstart code uses no post-ES2022/ES2023 syntax. The latent risk is that CI now typechecks the doc-synced .ts snippets under target: esnext, so a future edit using post-ES2023 syntax (e.g., a new ECMAScript proposal) would compile cleanly in CI but fail for a user who copies the doc tsconfig.json verbatim. It's primarily a documentation-consistency issue, the same class as the module/moduleResolution drift already addressed in this PR.

How to fix

Either:

• Update the doc tsconfig.json blocks to "target": "esnext" / "lib": ["esnext"] so they match the example's effective config, or
• Add "target": "ES2023" / "lib": ["ES2023"] (and "target": "ES2022") overrides back into the example compilerOptions so the example matches what the docs advertise.

Optionally, give the doc tsconfig blocks a source= attribute (or similar) so sync:snippets can catch this class of drift going forward.

What the bug is

The codemod that strips .js extensions touched scripts/cli.ts (lines 2–8), but every relative import in that file points at paths that ceased to exist when the repo was restructured into a monorepo:

import { Client } from '../src/client/index';
import { SSEClientTransport } from '../src/client/sse';
import { StdioClientTransport } from '../src/client/stdio';
import { Server } from '../src/server/index';
import { SSEServerTransport } from '../src/server/sse';
import { StdioServerTransport } from '../src/server/stdio';
import { ListResourcesResultSchema } from '../src/types';

There is no <repo>/src/ directory. Source now lives under packages/{client,server,core}/src/. Several of the imported symbols (SSEServerTransport) don't exist anywhere in packages/ either — the server-side legacy SSE transport was removed.

Why nothing catches it

• No tsconfig sees the file. There is no root tsconfig.json, and no package tsconfig has scripts/ in its include. pnpm typecheck:all walks per-package configs and never visits scripts/cli.ts.
• The npm scripts that reference it can't run it. packages/client/package.json:78-79, packages/core/package.json:48-49, and packages/server/package.json:81-82 all declare scripts like tsx scripts/cli.ts server / tsx scripts/cli.ts client — but those run from the package directory, which has no scripts/ subdirectory. The only scripts/cli.ts is at the repo root.

So the file is simultaneously unbuildable, untypechecked, and unreachable.

What this PR did to it

The codemod blindly stripped .js from each of the seven imports (the only change in the diff for this file). This neither fixes nor worsens anything — '../src/client/index.js' and '../src/client/index' are both nonexistent — but it adds churn to the diff and gives the file a false appearance of being maintained.

Step-by-step verification

1. ls <repo>/src → No such file or directory. The base ../src/ of every import in the file doesn't exist.
2. grep -r 'SSEServerTransport' packages/ → no matches. Even the symbol on line 6 was removed in the v2 rewrite.
3. No <repo>/tsconfig.json exists; the project's tsconfigs are per-package and none lists scripts/.
4. packages/client/scripts/, packages/core/scripts/, packages/server/scripts/ → none exist, so tsx scripts/cli.ts ... from any of those package dirs fails with Cannot find module.

Impact

None at runtime — the file was already dead and stays dead. The cost is maintenance noise: future codemods will keep touching it, and a contributor reading the diff might assume scripts/cli.ts is a working CLI.

Suggested fix

Delete scripts/cli.ts and the three dangling server/client npm scripts that point at it (in packages/client/package.json, packages/core/package.json, packages/server/package.json). This is pre-existing cleanup, not a regression introduced by this PR — but since the codemod touched the file anyway, it's a natural moment to remove it instead of continuing to edit a corpse.